130 - sendheaders message
BIP: 130 source Layer: Peer Services Title: sendheaders message Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130 Status: Proposed Type: Standards Track Created: 2015-05-08 License: PD Table of ContentsAbstractMotivationSpecificationAdditional constraintsBackward compatibilityImplementationCopyright Abstract Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". Motivation Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows: A node (N) announces the new tip with an "inv" message, containing the block hashA peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the...
339 - WTXID-based transaction relay
BIP: 339 source Layer: Peer Services Title: WTXID-based transaction relay Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339 Status: Draft Type: Standards Track Created: 2020-02-03 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementationCopyright Abstract This BIP describes two changes to the p2p protocol to support transaction relay based on the BIP 141 wtxid of a transaction, rather than its txid. Motivation Historically, the inv messages sent on the Bitcoin peer-to-peer network to announce transactions refer to transactions by their txid, which is a hash of the transaction that does not include the witness (see BIP 141). This has been the case even since Segregated Witness (BIP 141/143/144) has been adopted by the network. Not committing to the witness in transaction announcements creates inefficiencies: because a transaction's witness can ...
90 - Buried Deployments
BIP: 90 source Title: Buried Deployments Author: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD Table of ContentsAbstractMotivationConsiderationsSpecificationImplementationReferencesAcknowledgementsCopyright Abstract Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. Motivation BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block versio...
338 - Disable transaction relay message
BIP: 338 source Layer: Peer Services Title: Disable transaction relay message Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338 Status: Draft Type: Standards Track Created: 2020-09-03 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationCompatibilityImplementationReferencesCopyright Abstract This BIP describes a change to the p2p protocol to allow a node to tell a peer that a connection will not be used for transaction relay, to support block-relay-only connections that are currently in use on the network. Motivation This proposal is part of an effort to increase the number of inbound connections that a peer can service, by distinguishing peers which will not relay transactions from those that do. Since 2019, software has been deployed[1] which initiates connections on the Bitcoin network and sets the transaction relay field (introduced by BIP 37 and also defined in BIP 60) ...